Often, a client computer uses a network interface card (NIC) to communicate on a network with a host computer or with other client computers. The NIC typically implements the hardware and software necessary to prepare outgoing data and interpret incoming data in a format protocol and speed appropriate for the network. Data may be transmitted at a variety of speeds. However, only two standard data transmission speeds, 10 megabits per second (Mbps) and 100 Mbps, will be referred to herein. The NIC uses a clock signal to enable logic devices therein to transmit and accept data and to perform other functions. Proper implementation of one or more clock signals into the NIC is critical to provide error-free data transmission. A clock-enable circuit is a method whereby a clock signal is introduced into a NIC.
Referring to Prior Art FIG. 1A, a time trace 100 of multiple logic signals of a clock-enable circuit is presented. Clock signal 102 is input to the clock-enable circuit at a specific frequency and a specific pulse width 104. Enable signal 106 is also input into the clock-enable circuit to tell the clock-enable circuit when to provide the input clock signal 102 as an output signal 108.
Enable signal 106 is referred to as asynchronous because it can be switched on or off at any time, not just at the positive or negative edge of a pulse. Hence, if enable signal 106 goes to a high logic level 110 part-way through a high logic level 112 of clock signal 102, then output signal 108 has a high logic level 114 with a pulse width 116 that is shorter than the actual pulse width 104 of clock signal 102. This phenomenon is referred to as a glitch. It produces a clipped clock signal because the pulse width 116 of the output signal 108 is shorter than the pulse width 104 of the input clock signal 102.
The glitch in output signal 108 may cause downstream logic devices to malfunction. Logic devices timed to output signal 108 require specific pulse-widths for set-up and hold times, for changing states, propagating signals and, in general, becoming stable. More specifically, a glitch in the clock signal would most likely cause the Media Access Control (MAC) logic to go into an unknown state, thereby locking up the NIC or the host computer. A software reset may be insufficient to recover the transmitted data or to correct the locked-up computer. In such a case, a hard restart would be required to reset the hardware. Hence, a need exists for an asynchronously enabled clock circuit to provide a glitch-free and unclipped output signal with pulse widths identical to the input clock signal.
In the prior art, a block of logic called the auto-negotiation block, external from the Ethernet controller, provides a glitch-free output clock signal and allows switching between multiple clock input signals. The output clock signal from the auto-negotiation block is communicated to the Ethernet controller, the brains of the network interface card, and to the MAC portion of the logic. Because the external auto-negotiation block in the prior art always provides a glitch-free output clock signal, software can be used to manage switching from one input clock signal to a second input clock signal. This switching is called auto negotiation switching (ANS). ANS is a method of negotiating the speed of data transmission when the network adapter of an NIC is plugged into any hub (switch), e.g. 100 Mbps full-duplex or 10 Mbps half-duplex.
For example, the managing software can simply tell the external auto-negotiation block to switch clocks at any time without concern about a clock glitch because the external auto-negotiation block already guaranteed a glitch-free clock signal. The Ethernet-software driver polls the auto-negotiation status registers at a regular interval, and if the auto-negotiation status changes, the driver takes the appropriate action, such as resetting the MAC. However, as mentioned, the auto-negotiation block is an external component that consumes space and requires interconnections. Furthermore, the software implementation of switching consumes more time than would a hardware implementation. Thus, a need arises to reduce the size and the quantity of external components, and to reduce software delays occurring in an external auto-negotiation block.
One method of satisfying this need is to internalize the auto-negotiation block onto the Ethernet controller circuit as an application specific integrated circuit (ASIC). Unfortunately, the software used to control the external auto-negotiation block cannot be used to control an internal (ASIC) auto-negotiation block. The initial clock switching during the computer startup would most likely create an unknown condition in the MAC logic or the internal auto-negotiation circuit before any software code could be implemented. For example, when the network interface is first powered up, the client negotiates through the physical layer with host to determine the appropriate transmission protocol. The physical layer automatically communicates at a default 10 Mbps speed. If the NIC is plugged into a 100 Mbps hub, then the auto-negotiation logic will automatically switch (e.g. asynchronously) from 10 Mbps to 100 Mbps (i.e. from 10 MHz to 25 MHz). Because this switching operation is asynchronous a glitch is highly likely. Consequently, a system failure would most likely follow.
Besides the initial clock instability, switching between multiple clock signals requires all input clock signals to be glitch-free. If switching was performed synchronously with the clock signal, a glitch would not be a concern. However, because the user has the capability of physically disconnecting and reconnecting to the network connection at any time, the process of switching becomes asynchronous. By eliminating the external auto-negotiation logic block, its characteristic of providing glitch-free clock signals despite the asynchronous switching is no longer available. Hence, software cannot reliably be used for switching between clock signals with potential glitches. If a glitch occurs during the switching of a clock and a data packet was actively being transmitted at the same time, then the data would probably be lost. Additionally, the glitch would most likely cause the client computer to freeze-up, thereby requiring a hard restart. Consequently, a need arises for an internal auto-negotiation clock-switching circuit that provides glitch-free clock signals for start-up and for switching.
Referring now to Prior Art FIG. 1B, a time trace 150 of multiple glitch-free enabled clock signals of a clock-switching circuit is presented. In this scenario, a first output signal 152 currently being output from a auto-negotiation block will be changed to a second output signal 154 having a frequency the same as, or different from, that of the first. The switching will occur as a result of changes in asynchronous enabling signals 156 and 170. While first output signal 152 and second output signal 154 might both have glitch-free, or unclipped, wave forms, the timing of disabling first output signal 152 and of enabling second output signal 154 could create a glitch in the final output 162 of the auto-negotiation logic block. For example, if first output signal 152 is disabled at a low logic period 158, and if second output signal 154 is enabled at a high logic period 160 without sufficient wait time, then the composite final output 162 will appear as having a glitch 164. Hence, a need arises for a clock-switching circuit that can guarantee asynchronous switching between unclipped clock signals without creating a glitch from the switching process.
As previously mentioned, the NIC operates at multiple data rates that are regulated by their respective clock rates. The multiple data rates exist both for a transmitted signal as well as a received signal. Hence, the transmitted signal uses multiple clock frequencies and the received signal uses multiple clock frequencies. However, the method by which a clock frequency is established for a transmitted signal is different from that for a received signal. A transmission signal operating at 100 Mbps uses an ASIC oscillator clock located on the NIC that operates at 25 MHz. Likewise, a transmission signal operating at 10 Mbps uses an ASIC clock located on the NIC that operates at 10 MHz.
In contrast, the received signal always operates from a recovered clock generated by a phase lock loop (PLL) circuit. The PLL locks onto the frequency and phase of the data stream that is received at the NIC from the switch (hub). If the signal received at the NIC was sent by the hub at 10 Mbps, then the recovered clock establishes a 10 MHz clock. Likewise, if the signal received at the NIC was sent by the hub at 100 Mbps, then the recovered clock establishes a 25 MHz clock. Unfortunately, only the 100 Mbps hub sends a signal to the PLL at the client computer regardless of whether data is being sent or not. The 10 Mbps hub only sends a signal when it is actually transmitting data to the client. Hence, the 10 Mbps based recovered clock has many instances when a recovered clock cannot be established.
The conventional logic arrangement, e.g. external auto-negotiation block and undivided physical layer, requires a 25 MHz clock signal input as the first clock. Additionally, conventional designs always keep one clock running. If at least one clock is not running, the circuit logic will not reset properly and thereby prevent switching. Conventionally, if a clock is not recovered, circuit logic will multiplex (MUX) in another clock to keep the recovery logic running. A MUX clock is created by dividing down an existing clock such as the 25 MHz clock or by creating a new clock based on its own crystal. Hence, a conventional NIC may need two crystals, one at 10 MHz and a second at 25 MHz. In this manner, if a clock cannot be recovered due to the absence of a data stream, the NIC could switch over to another (MUX) clock from an external source (via asynchronous switching). Unfortunately, an additional clock increases cost, quantity of components, and circuit complexity. Subsequently a need arises for a clock switching circuit that can function with or without a recovered clock signal.
In summary, a need exists for an asynchronously enabled clock circuit to provide an output clock signal with unclipped pulse widths approximately identical to the input clock signal. Furthermore, a need exists to reduce the size, external components, and software delays occurring in a clock-switching circuit. At the same time, a need exists for the clock-switching circuit to provide an unclipped clock output signal at start-up and during switching. Besides the aforementioned needs, a further need exists for the clock-switching circuit that can guarantee asynchronous switching between unclipped clock signals without creating a glitch in the output from the switching process. Finally, a need exists for a clock-switching circuit that can exist with or without a recovered clock signal.